In recent times, distributed processing has become increasingly important within the field of data processing. To implement distributed applications and other programs, it is frequently useful to permit interprocess communication. Specifically, it is convenient to allow one process or program executing on one platform to be able to communicate with another process or program operating on a second platform. As an example, a database of information may be managed on one platform by a management process. Processes on other platforms may communicate with the management process to access or modify information contained in the database.
Various schemes or me or mechanisms have been implemented to address this desired functionality. Specifically, remote procedure call (RPC) systems have been developed to allow a program on one compute to execute a procedure on another computer. The first program may communicate various arguments pursuant to the RPC protocol for delivery to a process operating on the other computer. The second process will utilize the arguments to cause a particular task or tasks to be performed. Often, this involves constructing a return message for the first program containing results prompted by the initial arguments. Other object oriented approaches (such as CORBA and DCOM) have been created to facilitate similar interprocess communication.
RPC has typically been implemented utilizing an RPC server. The RPC server acts to receive messages from various clients for distribution to other clients. The RPC server does not perform any appreciable amount of processing upon the messages. Instead, the RPC server acts as a queuing agent before transporting messages to their destination where the requested procedure will be executed.
RPC servers have been implemented via a main thread associated with a particular socket on a server platform. In UNIX and some other operating systems, a socket is an operating system software object that connects an application to a network protocol. In UNIX for example, a process can send and receive TCP/IP messages by opening a socket and reading and writing data to and from the socket. A socket is advantageous for some applications, since a programmer need only worry about manipulating the socket and can rely on the operating system to actually transport messages across the network correctly.
To communicate a procedure call to another client in an RPC architecture, a process on the client would first communicate the procedure call to a main thread on the RPC server via a particular socket. The main thread would then place the procedure call in a queue. Eventually, the main thread would establish a socket connection to a given process on the destination client to communicate the procedure call. These steps necessarily involve a significant degree of latency. First, the main thread must be available before the originating process can perform the initial communication. Secondly, the initial communication is a synchronous process. Also, acknowledging the receipt of the procedure call by the main thread involves an amount of delay.
It is possible to create a multithreaded RPC server. However, a multithreaded RPC server does not provide significant performance gains unless the RPC server performs a significant amount of processing of messages. If the RPC server expends the majority of its processing capacity on communicating messages via sockets, the multithreaded approach will not produce any appreciable improvement. This effect is a result of operating system limitations. Specifically, operating system constraints limit operation of socket communication to a single thread at a time. Accordingly, multiple threads cannot communicate via sockets more efficiently than a single thread.